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Abstract 


This document updates the specification of the component matching 
rules for Lightweight Directory Access Protocol (LDAP) and X.500 
directories (RFC3687) by collecting the Abstract Syntax Notation One 
(ASN.1) definitions of the component matching rules into an 
appropriately identified ASN.1 module so that other specifications 
may reference the component matching rule definitions from within 
their own ASN.1 modules. 


1. Introduction 


The structure or data type of data held in an attribute of a 
Lightweight Directory Access Protocol (LDAP) [LDAP] or X.500 [X500] 
directory is described by the attribute’s syntax. Attribute syntaxes 
range from simple data types, such as text string, integer, or 
boolean, to complex data types, for example, the syntaxes of the 
directory schema operational attributes. RFC 3687 [CMR] defines a 
generic way of matching user selected components in a directory 
attribute value of any arbitrarily complex attribute syntax. 


This document updates RFC 3687 by collecting the Abstract Syntax 
Notation One (ASN.1) [ASN1] definitions of RFC 3687 into an 
appropriately identified ASN.1 module so that other specifications 
may reference these definitions from within their own ASN.1 modules. 
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2. Module Definition for Component Matching 


ComponentMatching 
{iso(1) 2 36 79672281 xed(3) module(0) component-matching (4) } 


-- Copyright (C) The Internet Society (2004). This version of 
-- this ASN.1 module is part of RFC 3727; see the RFC itself 
-- for full legal notices. 


DEFINITIONS 
EXPLICIT TAGS 
EXTENSIBILITY IMPLIED ::= BEGIN 


IMPORTS 
MATCHING-RULE, 
RelativeDistinguishedName 
FROM InformationFramework 
{joint-iso-itu-t ds(5) module (1) 
informationFramework(1) 4} ; 


ComponentAssertion ::= SEQUENCE { 

component ComponentReference (SIZE(1..MAX)) OPTIONAL, 

useDefaultValues BOOLEAN DEFAULT TRUE, 

rule MATCHING-RULE. &id, 

value MATCHING-RULE.é&AssertionType } 
ComponentReference ::= UTF8String 
ComponentFilter ::= CHOICE { 

item [0] ComponentAssertion, 

and [1] SEQUENCE OF ComponentFilter, 

or [2] SEQUENCE OF ComponentFilter, 

not [3] ComponentFilter } 
componentFilterMatch MATCHING-RULE ::= { 

SYNTAX ComponentFilter 

ID { 1 2 36 79672281 113 2 } } 
allComponentsMatch MATCHING-—RULE = { 

ID { 1 2 36 79672281 113 6 } } 
directoryComponentsMatch MATCHING-RULE ::= { 

ID { 1 2 36 79672281 113 7 } } 


—- Additional Useful Matching Rules -- 


rdnMatch MATCHING-RULE ::= { 
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SYNTAX RelativeDistinguishedName 


ID { 1 2 36 79672281 113 3 } } 
presentMatch MATCHING-RULE ::= { 

SYNTAX NULL 

ID { 1 2 36 79672281 1 13 5 } } 


END 


The InformationFramework ASN.1 module from which the MATCHING-RULE 
and RelativeDistinguishedName definitions are imported is defined in 
x.501 [X501]. 


The object identifiers used in this document have been assigned for 
use in specifying the component matching rules by Adacel 
Technologies, under an arc assigned to Adacel by Standards Australia. 


3. Security Considerations 


This document collects together the ASN.1 definitions of the 
component matching rules into an ASN.1 module, but does not modify 
those definitions in any way. See RFC 3687 [CMR] for the security 
considerations of using the component matching rules. 
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6. Full Copyright Statement 


Copyright (C) The Internet Society (2004). This document is subject 
to the rights, licenses and restrictions contained in BCP 78 and 
except as set forth therein, the authors retain all their rights. 


This document and the information contained herein are provided on an 
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Intellectual Property 
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